The deployment of an application, protocol, or other executable in a distributed computing environment can result in various execution errors which affect the operation of the application, protocol, or other executable and can impact the operation of the distributed computing environment itself. Although computing application developers/programmers attempt to identify and resolve execution errors in the application, protocol, or other executable prior to deploying the application in the distributed computing environment, often execution errors will only appear after deployment (i.e., not in a development and/or test environment). The ability to identify such execution errors after deployment has been addressed with a number of currently deployed practices.
However, finding computing environment execution errors (e.g., bugs) in distributed computing environments is a notoriously hard problem. Conventionally, developers will deploy one or more computing application scripts and/or applets that when executed operate to exercise computing environments in desired manners (e.g., particular ways) that have a high probability of eliciting bugs. However, given the numerous and different orders in which events can occur and the number of ways in which components can fail, manual testing achieving moderate completeness is rendered an extremely arduous, time-consuming, and costly task.
Current practices do not allow for the execution of error execution identification tests utilizing highly relevant sources of non-determinism as identified by the distributed computing environment operator (e.g., programmer of the distributed computing application, protocol, or other executable in a distributed computing environment). Additionally, current practices do not consider providing more than one execution path using test code and/or application code instrumentation for an execution error test to identify additional possible sources for error executions. As such, with currently deployed practices, the tests for execution errors can run repeatedly over a prolonged duration without eliciting previously observed but non-frequent execution errors. This can result in the need for additional computational and, more importantly, manual resources to identify execution errors.
From the foregoing it is appreciated that there exists a need for systems and methods to ameliorate the shortcomings of existing practices.